Click Here!
home account info subscribe login search My ITKnowledge FAQ/help site map contact us


 
Brief Full
 Advanced
      Search
 Search Tips
To access the contents, click the chapter and section titles.

Oracle Performance Tuning and Optimization
(Publisher: Macmillan Computer Publishing)
Author(s): Edward Whalen
ISBN: 067230886x
Publication Date: 04/01/96

Bookmark It

Search this book:
 
Previous Table of Contents Next


Chapter 20
BLOB System

Oracle can store Binary Large Objects (BLOBs) using the RAW or LONG RAW data type available from Oracle. BLOBs are used to store data that cannot be stored in a textual form. Such data can have any of the following forms:

  Images. These images may have any of several formats, including GIF and JPEG.
  Video. These types of images may be in MPEG or some other format.
  Audio. Audio data can be stored in a variety of formats, including PCM, ADPCM, DSP, GSM, and so on.
  Documents. Scanned documents can be stored as a BLOB.

These and many other types of data can be stored in an Oracle database using the RAW or LONG RAW data type. These data types permit you to store any type of data that does not fit into the typical data types. This allows you immense flexibility in the type and amount of data you can store in a database. With the increased popularity of multimedia applications and data, the effective storage of such data is becoming more important.

Characteristics of BLOBs

Binary large data is a term used to describe any type of binary data that is significant in size and stored on a computer. Although BLOBs do not have to be stored in a database, for the purposes of this book, only data stored in an Oracle database is addressed.

BLOBs stored in an Oracle database usually exhibit the following characteristics:

  Significant size. Each record is significant in size. Although the size depends on your particular database and application, with BLOBs, the objects can be 1M in size or larger.
  Binary data. BLOB data is binary by definition.
  Strict response time criteria. Because the data can consist of sources that require continuous data feeds (such as video and audio), the response-time criteria may be strict. When numeric data is momentarily interrupted, the user hardly notices, but when an audio or video stream is interrupted, it is quite noticeable.
  Compression. Because the data is binary and large, it may or may not be stored in a compressed state. This depends on the database and the application.

These are the general attributes of binary large objects. The way this data is accessed is quite different from other types of applications described in the preceding chapters. The following section looks at the data access patterns for BLOBs.

Data Access Patterns

The data access patterns for a system used for BLOB storage are unique. One or more tables have records of a megabyte or more. When this data is accessed, it is a continuous data access to a single record. In the other types of database applications you have seen, it is unlikely that a single record is larger than a data block. With BLOBs, it is certain that a single record will span many data blocks.

System Load

The load you see when accessing BLOBs is different than the typical load you see with other types of RDBMS systems. With BLOBs, the load tends to be more on the I/O subsystem and less on the system processors.

In a typical OLTP, batch, or DSS system, the system processors are kept busy determining where to look for the next piece of data, completing some other function such as a sort, or performing aggregate functions. It is also normal for the I/O subsystem to spend most of its time seeking to new data rather than waiting for sequential data to be retrieved. In fact, in most type of RDBMS operations, it is normal for more time to be spent seeking than retrieving the data.

In a system used to access BLOB data, it is not unusual for more time to be spent retrieving the data than seeking to it. This reversal occurs because of the large amount of data associated with a typical BLOB record. It is not unusual for the BLOB system to spend a lot of time in I/O activities; therefore, it is less sensitive to the CPU horsepower of the system.

Because the data accesses to these large records are sequential, simply adding more disk drives to the system may not solve the problem. However, because most of these accesses occur simultaneously with other disk accesses, many of the concepts discussed in previous chapters still apply. A disk array can still be very beneficial.

Other tuning concepts also apply but may vary slightly from previous examples. The primary emphasis in accessing BLOB data is the I/O subsystem. The performance of your system is based primarily on the performance of the I/O subsystem.

Following is a list of the load characteristics of a BLOB system:

  Relatively few processes on the system. For the BLOB system, the Oracle Parallel Query option is not of any benefit.
  Extremely high network traffic. The primary function of this type of system is to provide some sort of data stream. Typically, this function is to service remote clients.
  Heavy I/O usage. The BLOB system depends heavily on the I/O subsystem. Although the accesses are sequential, multiple simultaneous accesses make this I/O random. By taking advantage of multiblock reads, sequential access is done as much as possible.
  Very little redo log usage during access, heavy usage during data loading. These types of systems are primarily used for data retrieval; however, adding data to the system can significantly affect the redo log.
  Very little or no use of rollback segments. Again, because BLOB functions consist of very little update activity, the rollback segments are hardly used. However, if data loading is done with INSERT statements instead of with the direct path loader, rollback segments may be affected.
  Moderate to heavy use of memory. Memory is used not only for the SGA but for each of the server processes that may be performing additional functions.

You can use these characteristics to help design and tune your BLOB system for optimal performance. The first step in this design process is to set goals for what you want to achieve.


Previous Table of Contents Next


Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited.